Improving Size Estimates Using Historical Data

business objects (Obj) 16 Basic abstract geoscience business objects, including projects, wells, well logs, markers, zones, and seismic data Concrete business object input/output (I/O) 15 Concrete input/output behaviors for abstract business object persistence mechanisms Data import/export filters (Filter) 14 Abstract factories, strategies, and GUI components for importing and exporting “foreign” data formats Application data factory (Data) 6 Abstract data object factory providing GUI components for user data selection, delivering observers of abstract business objects to application contexts Reusable GUI components (Component) 22 Reusable unit-labeling (feet/meters) text fields, data selection components, and calculation configuration components Application support components (Prefs) 15 User preference, window layout, and session save/reinstantiation support Application GUI (App) 73 User data display and editing, object property dialogs, and calculation setup dialogs and utilities that are not directly traceable to specific requirements (Tools). Estimation Study The estimation tools available to our development team included Cocomo II and Estimate Pro V2.0.2,3 (See the “Estimation Techniques” sidebar for a description of these and other estimator techniques.) Both of these tools generate estimates for the amount of effort, time, or cost, but they require input specifying the size of the work to be completed. The problem we faced throughout the project was estimating size. No one on the development team was trained in function-point analysis, so we loosely based our attempts at prediction on analogy methods and the Delphi principle of reaching consensus with individual, “expert” estimates. Without a defined, repeatable sizeestimation process, these predictions were little better than outright guesses. Finally, our failure to record our predictions—and subsequently compare the actual size against the N o v e m b e r / D e c e m b e r 2 0 0 0 I E E E S O F T W A R E 29 Software estimation techniques generally fall into one of three categories: ■ empirical techniques that relate observations of past performance to predictions of future efforts, ■ regression models that are derived from historical data and describe the mathematical relationships among project variables, and ■ theory-based techniques that are based on the underlying theoretical considerations of software development processes.1 For the purposes of this discussion, I merely draw a distinction between techniques that might help estimate size versus those used to estimate effort, schedule, and cost. A well-known and widely used regression technique is Cocomo (constructive cost model).2,3 The Cocomo II model estimates the effort, schedule, and cost required to develop a software product, accounting for different project phases and activities. This type of estimation method uses regression equations (developed from historical data) to compute schedule and cost by factoring in various project drivers such as team experience, the type of system under development, system size, nonfunctional product attributes, and so on. The SLIM (software lifecycle management) method4 is a theory-based technique1 that uses two equations to estimate development effort and schedule. The software equation, derived from empirical observations about productivity levels, expresses development effort in terms of project size and development time. The manpower equation expresses the buildup of manpower as a function of development time. Sizing techniques rely primarily on empirical methods. A few of these include the Standard and Wideband Delphi estimation methods, analogy techniques, the software sizing model (SSM), and function-point analysis. Observations and an understanding of historical project information can help predict the size of future efforts. The Delphi methods2,5 employ techniques for decomposing a project into individual work activities, letting a team of experts generate individual estimates for each activity and form a consensus estimate for the project. Estimation by analogy involves examining similarities and differences between former and current efforts and extrapolating the qualities of measured past work to future efforts. The SSM decomposes a project into individual modules and employs different methods to estimate the relative size of software modules through pair-wise comparisons, PERT (identifying the lowest, most likely, and highest possible sizes) estimates, sorting, and ranking techniques. The estimates are calibrated to local conditions by including at least two reference modules of known size. The technique generates a size for each module and for the overall project.6 Function-point analysis7 measures a software system’s size in terms of system functionality, independent of implementation language. The function-point method is considered an empirical estimation approach1 due to the observed relationship between the effort required to build a system and identifiable system features, such as external inputs, interface files, outputs, queries, and logical internal tables. Counts of system features are adjusted using weighting and complexity factors to arrive at a size expressed in function points. Although function-point analysis was originally developed in a world of database and procedural programming, the method has mapped well into the object-oriented development paradigm.8 References 1. R.E. Fairley, “Recent Advances in Software Estimation Techniques,” Proc. 14th Int’l Conf. Software Eng., ACM Press, New York, 1992. 2. B. Boehm, Software Engineering Economics, Prentice Hall, Upper Saddle River, N.J., 1981. 3. Barry Boehm et al., “Cost Models for Future Software Life Cycle Process: Cocomo 2.0,” Ann. of Software Eng. Special Volume on Software Process and Product Measurement, J.D. Arther and S.M. Henry, eds., Science Publishers, Amsterdam, The Netherlands, Vol. 1, 1995, pp. 45–60. 4. L.H. Putnam, “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Trans. Software Eng., Vol. 4, No. 4, Apr. 1978, pp. 345–361. 5. K. Wiegers, “Stop Promising Miracles,” Software Development, Vol. 8, No. 2, Feb. 2000, p. 49. 6. G.J. Bozoki, “Performance Simulation of SSM (Software Sizing Model),” Proc. 13th Conf., Int’l Soc. of Parametric Analysts, Int’l Soc. of Parametric Analysts, New Orleans, 1991, pp. CM–14. 7. A. Albrecht, “Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation,” IEEE Trans. Software Eng., Vol. SE-9, No. 6, 1983. 8. T. Fetcke, A. Abran, and T.H. Nguyen, “Mapping the OO-Jacobson Approach into Function Point Analysis,” Proc. TOOLS-23’97, IEEE Press, Piscataway, N.J., 1998. Estimation Techniques